Docker Swarm in 2023: When It Still Makes Sense

The popular narrative says Kubernetes won and Docker Swarm is dead. Reality is more nuanced. Swarm remains maintained (it’s part of Docker Engine), works perfectly in production, and for a specific slice of cases remains the right choice — not a legacy option. We cover when Swarm still makes sense, what costs less, and what limitations you accept in exchange.

The Real State in 2023

Some facts about the current state:

Swarm is integrated in Docker Engine — not a separate project that can be independently abandoned.
Receives regular maintenance though without flashy new features.
Mirantis acquired Docker Enterprise in 2019 and maintains the technology — it’s not orphaned.
Established adoption in small and medium organisations not needing Kubernetes complexity.

What it ISN’T in 2023:

Not the coolest, not what you’ll see in DevOps talks.
Doesn’t have the operator and tooling ecosystem of Kubernetes.
Not an option for large hyperscale.

When Swarm Is the Best Option

There are concrete cases where Swarm wins without dispute:

Small Teams Without Dedicated SRE

If your dev team is 5-15 people and you have no dedicated SRE/ops, Swarm costs significantly less to operate than Kubernetes:

Setup in minutes vs days.
Limited concepts (services, stacks, secrets, configs, networks). No CRDs, no operators, no Helm.
docker stack deploy -c stack.yml my-app and done.
Learning curve compatible with knowing Docker Compose.

For a 30-50-person organisation with 3-10 services, Swarm can deliver 95% of the value with 20% of the operational cost.

Self-hosted on VPS

For services hosted on owned VPSs (1-5 nodes), Swarm is the natural tool. Kubernetes at this size is over-engineering — most of its value is at scale you don’t have.

Typical deployments:

Own and client websites on a few VPSs.
Self-hosted stacks (Nextcloud, Mailcow, Gitea).
Small companies with their own infra.

Smooth Migration From Docker Compose

If you already use Compose in production (common in small companies), Swarm is the natural next step. Your docker-compose.yml files work almost without changes — you just add the deploy: field with replicas, resources, and placement.

Migrating to Kubernetes from Compose requires rewriting manifests, learning new concepts, configuring many pieces. Swarm is continuity.

Edge Computing in Mini-clusters

For 3-10-node edge clusters (remote offices, factories, geographically distributed locations), Swarm is light, simple, and enough. Kubernetes at edge requires specialised distributions (k3s, microk8s) that add their own complexity.

When Kubernetes Is Clearly Better

Honesty: Swarm doesn’t scale to every case. K8s wins when:

You need advanced operators. PostgreSQL HA, Cassandra, Kafka clusters — Kubernetes has mature operators, Swarm doesn’t.
Strong multi-tenancy with namespaces. Swarm has no real equivalent of namespaces.
Sophisticated autoscaling. HPA/VPA, autoscalers based on custom metrics — Swarm has manual or very basic scaling.
Service mesh, ingress controllers, mature GitOps. The whole CNCF ecosystem aligns with K8s.
Hire-ability. In 2023 many more people know Kubernetes than Swarm.
Multi-cluster cross-region. K8s with federation or tools; Swarm is single-cluster.

For an organisation with 20+ services, multiple teams, and enterprise needs, K8s is the right choice.

What You Accept With Swarm

If you choose Swarm, you assume some limitations:

Limited ecosystem. Helm, ArgoCD, Backstage — all that is Kubernetes-only.
Simpler networking (VXLAN-based overlay). Works but isn’t CNI with plugins.
No granular RBAC comparable to K8s. More limited roles.
Smaller documentation and tutorials. Any “modern” problem has 100 K8s answers, 5 Swarm answers.
No modern features like formal sidecar pattern. You can do it but less idiomatic.

For cases where these limitations aren’t a problem, they’re acceptable trade-offs.

Typical Swarm Stack in Production

An architecture I see working well in real projects:

Swarm cluster (1 manager + 2 workers, or 3 managers in HA)
   │
   ├── Traefik as proxy/ingress (with automatic Let's Encrypt)
   ├── PostgreSQL/MariaDB as Swarm service with bind volume
   ├── Apps in separate stacks (each client or domain = stack)
   ├── Portainer as management UI
   ├── Prometheus + Grafana + Loki for observability
   ├── Watchtower for auto-update (in monitor mode)
   └── Backups with restic to external object storage

Operable by one person. Reasonable to monitor. Covers the vast majority of own-hosting needs.

Essential Commands

For someone coming from Compose, the key concepts:

# Initialise Swarm
docker swarm init --advertise-addr <ip>

# Add worker
docker swarm join --token <token> <manager-ip>:2377

# List nodes
docker node ls

# Deploy stack
docker stack deploy -c stack.yml my-app

# List stacks and services
docker stack ls
docker service ls

# Service logs
docker service logs my-app_web -f

# Scale
docker service scale my-app_web=3

# Rolling update
docker service update --image nginx:1.25 my-app_web

# Remove stack
docker stack rm my-app

If you know Compose, you have 70% of Swarm already.

Conclusion

Docker Swarm is alive in 2023 and remains the right choice for cases where Kubernetes is over-engineering. Small teams, self-hosted, edge mini-clusters — all cases where Swarm’s simplicity and low operational cost are worth more than K8s’s advanced features. The “Swarm is dead” stigma is overblown: for the right case, it’s still the right tool. The honest important question is: do you need K8s, or do you need something simple that orchestrates containers?